PC-Blue - MS DOS Public Domain Library

home *** CD-ROM | disk | FTP | other *** search

/ PC-Blue - MS DOS Public Domain Library / PC-Blue MS-DOS Public Domain Library - NYACC.iso / vol174 / tutor < prev next >

Wrap

Text File | 1986-11-24 | 60.6 KB | 1,541 lines

ESIE The Expert System Inference Engine Tutor Lightwave Consultants August 1985 P.O. Box 290539 Tampa, FL 33617 Copyright 1985, All Rights Reserved. The ESIE distribution diskette, of which this tutor is one file, may be freely copied and distributed. Printed copies of this tutor, or this tutor without the rest of the files on the distribution diskette, may not be copied or reproduced in any form. Page 2 Table of Contents Introduction . . . . . . . . . . . . . . . . . . . . . . 3 What is Shareware? . . . . . . . . . . . . . . . . . . . 4 What is Artificial Intelligence? . . . . . . . . . . . . 5 Types of Artificial Intelligence . . . . . . . . . . . . 6 What is ESIE? . . . . . . . . . . . . . . . . . . . . . . 9 What I Need to Get Started . . . . . . . . . . . . . . . 10 Starting ESIE . . . . . . . . . . . . . . . . . . . . . . 11 The ESIE Top Level . . . . . . . . . . . . . . . . . . . 12 Some Example Knowledge Bases . . . . . . . . . . . . . . 13 Animal . . . . . . . . . . . . . . . . . . . . . . . 15 Doctor . . . . . . . . . . . . . . . . . . . . . . . 19 Glass . . . . . . . . . . . . . . . . . . . . . . . 21 Building Your Own Knowledge Base . . . . . . . . . . . . 22 Paying For and Obtaining the Next Version of ESIE . . . . 26 Bibliography . . . . . . . . . . . . . . . . . . . . . . 27 Biography . . . . . . . . . . . . . . . . . . . . . . . . 28 Page 3 Introduction ESIE (pronounced "easy") is the acronym for Expert System Inference Engine. ESIE is, according to many people working in Artificial Intelligence (AI), an "expert system shell." With ESIE you can put some "smarts" into your personal computer. You can build custom "knowledge bases" (KBs) that can be used to aid people, like you and me, in doing things that we would not be capable of doing, or doing as well, without the system. ESIE knowledge bases can be built to help us make decisions or to make our computers "more human." This manual is designed for the person who has absolutely no experience in the field of Artificial Intelligence (AI). This manual is intended to give you: a working knowledge of AI, help you learn about ESIE, give you enough information to build your own knowledge bases, and provide some tips for building better knowledge bases in the future. When you have completed this tutorial you should print and read the file MANUAL, which gives all the details concerning ESIE. For those of you who may by interested in the history of AI, please print and read the file HISTORY, which gives a short history of Artificial Intelligence. If you only intend on using ESIE with a knowledge base written for you, then you need only print and read the file USER. I assume that you have no experience in AI whatsoever, but I further assume that you have done some work, or at least some reading, in the operation of your computer. Neither this tutorial, nor any file distributed with ESIE, will try to educate you concerning your equipment. However, operation of ESIE is very straightforward and you need only know the rudiments (i.e. how to turn your computer on) to use the ESIE system. In any case, welcome to ESIE. ESIE is my own work and I take full responsibility for its abilities and its shortcomings. Page 4 What Is Shareware? Shareware is a software distribution concept. In shareware, it is believed: that people will pay for something they find useful, that most software costs too much, that copy protection schemes can sometimes be frustrating even to the most honest user, and that software users want to support software authors while not necessarily supporting the software middle men. Shareware is a marketing concept. The term was probably originally coined by Bob Wallace of Quicksoft, Inc. Mr. Wallace wrote PC-Write (c), a shareware full-feature text editor. I personally like PC-Write and prefer it as my own editor. I believe you will find PC-Write useful and to that end I will send you a copy of it if you "pay" for ESIE at the $145 level. Many of the Shareware ideas in ESIE come directly from PC-Write(c) and I offer my public thanks. ESIE is distributed under the Shareware concept. You receive the software first, from whatever source that may be, and pay only what you think the software is worth. You are free, and encouraged, to share copies of the distribution diskette with others. ESIE is marketed under the shareware concept. I prefer to think of ESIE as living software: software that continues to develop and get better, more powerful. I believe ESIE is a useful tool as it is, but can be improved. However, support for living software must come from someone. Even we software authors and AI researchers can't live on discovery and love alone. In shareware this support comes from you - the user. If you feel that ESIE is useful to you, send what your conscience dictates. ESIE is paid for on the honor system. However, if you send at least $75 you will receive the most recent version of ESIE, free. If you send at least $145 you will receive: the most recent version of ESIE, fully commented source code for ESIE (ESIE was written in Pascal), my sincere thanks for your support, a copy of PC-Write (c) - a shareware full-feature text editor fully compatible with ESIE, and access to a help line, all free. Your comments towards ESIE are solicited even if you do not desire support. For this, please print and fill out the file FORM and send it in. Mail and money for ESIE can be sent to: Lightwave Consultants; P.O. Box 290539; Tampa, FL 33617. Page 5 What is Artificial Intelligence? Now here is a good question. Whenever a bunch of knowledge engineers (KEs) get together for social hour this subject has a way of rubbing us the wrong way. In short, not even we can decide on a good definition of AI. I'll give you my view in a moment, but now for the currently "accepted" view: "I think of AI - Artificial Intelligence - as performance by computers of tasks which, if they are done by people, would require intelligence." (1) Although I have immense respect for Dr. Simon, and consider him to be one of the true "fathers" of AI, I have a little trouble with this definition. First, an argument can be struck (and has been - believe me), that ALL computer software fits this definition as any task the computer does would probably require intelligence if a person were doing the same thing. Second, if you define intelligence to mean the ability to remember facts than all computers have a 200+ IQ. Third, why restrict the definition to computers? Although my definition is not the accepted one, I think I have heard more than one (at least two) KEs voice their approval: "Artificial Intelligence occurs when a man-made system gathers data and makes a recommendation." You notice that I allow other systems besides computers to be considered. The recommendation part is key. A system that simply catalogues or computes is not AI under my definition. Also, an AI system does not have to make a recommendation to a human, it can even be to another system. Well, enough of that. For a working definition of AI, at least until the tide changes, consider it as any activity that a computer does that is human-like. Page 6 Types of Artificial Intelligence If you could isolate every type of activity a human does, then you probably have found all the different types of AI. Let me list some of the most active ones in existence today: Natural Language (NL) is the field where researchers are trying to get machines to understand natural English, or some other human language. It is not as easy as you might think. For a widely known example, the sentence "the spirit is willing but the flesh is weak", was translated into "the wine is agreeable but the meat is spoiled" by an NL program. Machine Vision (MV) is the area where researchers are trying to get machines to see. Some of this work can be the most fascinating research in the world. I recommend it if you are in the mood for a career change. Past research has been concentrating on understanding how humans see and trying to duplicate that process in machines. Now, I believe, the trend is to use the special capabilities of the machine, such as infared detection and laser range finding in order to give the machine vision. Expert system (ES) research is the area that ESIE fits in. It is involved with making the machine reason and think like a human. Although no current ES has creativity, I'm sure it will be classified as an ES when the creative capability is made. Nearly all, if not all, ESs in existence today run on the KB principle. Knowledge based systems is also the area that is receiving the most recognition from industry as it has advanced enough to be useful. In KB systems, human reasoning is coded into the computer in production rules. The set of these rules makes up the knowledge base. Machine Listening (ML) works with the area of synthetic speech. Both speech recognition and speech synthesis come under the heading of Machine Listening. This too is fascinating work, and some real breakthroughs are expected very soon. Robotics works primarily in the area of motor control, tactile processing, and location determination. Robotic companies are increasing their sphere, however, and I'm sure they will soon be using all the capabilities of AI. There are two typical applications in existence today where expert systems are used. One is the area of decision tree applications and the other is in the area of data query. In decision tree systems a solution set is coded into a machine to solve a particular problem set. A good example of Page 7 decision tree systems are medical systems. In these, a typical first question might be: "Does the patient have a fever?". Based on the answer to that question an entire area of diseases will be eliminated, and the next level of the tree will be selected. Many knowledge bases today are built to run in the same "inference engine." These inference engines can use the rules in a multitude of different KBs, so they are useful in many tasks. An inference engine is the computer program that captures the raw inferencing power of the human mind. It uses the knowlege in the KB to act with human reasoning capability. In data query systems there is typically a natural language front end. This front end allows the end user to query a data base in natural English commands. The system has to solve for what the end user really wants and then go get and manipulate the appropriate data. An example of this type of system is where the question might be asked: "Should I hire more people before the year ends?" Both of the above are applications in knowledge based systems. While neither are becoming static in their application, they are becoming somewhat standard in implementation. A third form of expert, or knowledge based, system involves the process. This type of ES has been largely ignored by the AI community, but is starting to get large press in AI journals and papers. It is receiving notice in corporations due to its low cost and quick payback period. A process based system is trying to assist a human in completing some task. The goal in process based systems (PBS) is to automate that terribly lengthy, hard-to-read, impossible-to-use manual or intruction set. The interactive capability of PBSs are one of their nice features. ESIE can be used to build a PBS, but its main intent is for decision algorithms, where a decision or goal is to be reached. Expert systems are those computer applications that code human knowledge, usually from one or more human experts in the target field, into a form were the machine can mimic that expertise. The human expertise is coded in one or more files called the "knowledge base" (KB). Expert systems can be self-improving with time. That is, it is possible to build an ES that adds more information to its knowledge base as it is being used. Many practitioners argue against adding this capability, as it is possible for the KB to become indeterminant when conflicting rules are added. Page 8 If you want to know more about AI in general, then please print and read the file HISTORY. Page 9 What Is ESIE? ESIE is the acronym for Expert System Inference Engine, and that is exactly what it is. ESIE loads in a knowledge base, and builds inferences out of the rules contained therein, to act like an advisor. It is an Artificial Intelligence expert system shell. An infinite multitude of knowledge bases can be used by ESIE. What is an expert system shell (ESS)? ESSs are used to take the rules coded in the knowledge base and use these rules in a consulting session with a person. The person using the ESS with the KB to help him reach a decision is called the user. The coding of the rules into the KB is done by someone called the knowledge engineer. The normal gamut of expert systems (ES) can be built for and used by ESIE. Tools such as computer system configurators, medical experts, oil and gas exploration, etc, can all be done in ESIE. The acronym was also selected because ESIE is easy to use. ESIE is much easier to use than most ESSs available today. I can vividly remember thinking, "They've got to be kidding" with at least three different ESSs. Further, I am sure that if I uncovered one more "undiscovered" bug in an ESS that I would be a permanent resident at Bellevue. ESIE has been fully tested and checked out, and since it was written in Pascal, it should hold you in good stead. If you were, or are, currently working for a corporation or university then you are also aware of the difficulty in getting management approval for a very expensive piece of equipment. Most AI equipment and software is prohibitively expensive except for the best funded AI departments. ESIE is built to put some competitiveness into the ESS market. ESIE is very inexpensive and rivals many ESSs in power and it beats nearly all in speed. Also, for markets, ESIE is uniquely fitted. Knowledge based inference engines have a rather small market at present, but that soon may change. I hope the advent of low cost and readily available software might help the spread and acceptance of AI. Page 10 What I Need to Get Started In order to use ESIE you don't need much at all. For hardware you will need: an MS-DOS (r) or IBM (r) computer with at least 128 KB of RAM, and a color or monochrome monitor. ESIE should run on any MS-DOS (r) computer, (it has been tested on several), but I just can not guarantee that it will run on your particular machine. ESIE will run on the IBM PC jr, PC, XT, and AT (r). You will also need the ESIE distribution diskette, DOS 2.0 or higher, and a compatible word processor. Read the sections: ESIE Requirements and The ESIE Distribution Diskette in the manual for more information. You probably received everything you needed when you got the ESIE distribution diskette. Page 11 Starting ESIE Getting ESIE fired up will probably be one of the easiest things you do today. The only two files you need in the computer to use ESIE are the ESIE.COM file and the file where the KB is. Of course, you may have as many files out there as you wish. For purposes of demonstration, it will be assumed that you are using the ANIMAL example KB provided with the distribution diskette. When you start to build your own KBs, simply substitute that file for ANIMAL. ESIE will run in any drive and directory, including hard disks, as long as the ESIE.COM and KB files are present. When you have at least the above two files where you want them, simply type in ESIE at the DOS prompt. The ESIE introductory screen will appear. It contains information about the Shareware concept and some benefits you will receive if you pay for your copy of ESIE. At the top of the introductory screen is a prompt asking you to supply the file name where the knowledge base may be found. Type in ANIMAL. If the file exists, then ESIE will attempt to load that file. If no loading errors are found, then ESIE will take you to the top level. If there are errors in loading the KB, then ESIE will list where it found the errors and return you to DOS. If the file does not exist, then you have the option of trying again. Just hitting the 'Y' or the 'N' key will answer this prompt. ESIE loads files faster than most, if not all, other expert system shells, but be patient if you are loading a very large KB, especially from floppy diskette. Page 12 The ESIE Top Level You will know when you have reached the top level by the distinctive ESIE prompt. It looks like this: "==>". At the top level you have four different command options: TRACE ON, TRACE OFF, GO, and EXIT. While you can have as many leading and trailing blanks as you wish, ESIE is not quite free form on the command line; you must have one and only one space between the TRACE and YES/NO options. Other than that, ESIE is free form. Importantly, ESIE is case insensitive. Caps look just the same as smalls to ESIE. This is also true in the KB and in end user responses. ESIE is case insensitive everywhere. I like this feature: I hate building rules to take care of the same idea but duplicated everywhere to take care of case, and the idea that a variable means something different because the first letter is capitalized drives me up the wall. When you first enter the top level, trace is off by default. You can turn trace on using the TRACE ON command. Use trace when you are building your own KB and want to follow execution in order to debug the KB. Turning trace on will tell the system to constantly keep you informed of what it is currently looking for and what information it has learned. You can turn the trace back off again by entering the TRACE OFF command. The GO command is the command to tell ESIE to begin a consultation with the KB that was loaded. ESIE will continue with this consultation until it is complete or until an error is found in the logic of the KB. You may not turn trace on or off once a consultation has begun. If the user types in TRACE ON, TRACE OFF, GO or EXIT in response to a question, then ESIE will treat that as the response to the question. Once ESIE has completed the consultation, or found an error in the logic of the KB, it will return you to the top level for additional commands. Use the EXIT command in order to leave ESIE and return to DOS. After a consultation is complete, you have the option of entering ANY of the four commands, including GO, again. Page 13 Some Example Knowledge Bases In order to get you used to the ESIE rule structure, three sample KBs have been included on the distribution diskette. ANIMAL is a KB that plays "twenty questions" with you in order to find out what type of animal you are thinking about. Before typing in 'GO' to ESIE, after loading the ANIMAL KB, think of an animal you want ESIE to try and find. Answer the questions put to you about the animal and ESIE will find out what animal it is in far less than twenty questions. ANIMAL is a decision tree KB that is fully structured. A fully structured KB indicates that there is a terminating leaf on every path of the decision tree. In a fully structured KB it is impossible for the rules in the KB to be mixed up or out of order - there is one and only one path to every single goal in the KB. These types of KBs usually take the most effort to build, but are the most satisfying in their completion. You generally "map out" how the information should look before you begin coding. For example: type.transportation /\ / \ / \ / \ /2.wheels\ 4.wheels /\ /\ / \ / \ / bike car \ /motor \ /\ \ / \ truck / \ / \ moped bicycle Note that the leaves can be similar, but there is a terminating leaf for every path in the tree. In these types of KBs, the user response is usually limited to YES and NO. ANIMAL is much like this. This is what a session with ANIMAL looks like. The splats indicate output from ESIE: go Does your animal have a backbone? * yes Page 14 Is the animal warm blooded? * yes Normally, does the female of your animal nurse * its young with milk? * yes Does your animal eat red meat? * yes Does your animal have finger wings? * no Does your animal have an opposing thumb? * yes Does your animal have a prehensile tail? * no Is your animal nearly hairless? * yes * I think your animal is a MAN * * I have completed this analysis. * * ==> * DOCTOR is a KB that is used to diagnose diseases in children. Do not take DOCTOR too literally, please. I am no physician, and the information in the KB came out of a single book. The KB was built in about 8 hours. The DOCTOR KB is there just to show off ESIE and is not meant to replace your physician. DOCTOR is a decision tree KB and is not fully structured. I coded DOCTOR and ANIMAL in two distinct styles in order to demonstrate ESIE's capabilities. GLASS is rather special for me. First, I didn't write it. I asked a friend of mine to be one of the beta testers for ESIE and she came up with GLASS. She has no experience in AI whatsoever. GLASS demonstrates ESIE's ease of use. GLASS is used to give an evaluation of antique or depression era glass, which has gathered quite a following from what I understand. Page 15 Some Example Knowledge Bases Animal ANIMAL is a fully structured decision tree knowledge base. In order to build ANIMAL I gathered information concerning the classification of the animal kingdom. Gathering information on any subject that you wish to put into an ES will probably be the toughest part of your job as a KE. I good approach I've found is to begin by listing all the possible terminations of the decision tree. In ANIMAL all the terminations are the different animals, such as BEAR, FOX, etc. Then, using additional information, group the terminations into categories at the highest possible level and in as few categories as possible - hopefully two. In ANIMAL, the highest categorization offered by my information was does the animal have a backbone? I know what you are thinking: that is not a good classification if one considers all the possible animals in the world. But I was not working with all the possible animals in the world, I decided at the outset to limit the number of animals to those that a person has a pretty good chance of thinking about. This included all the mammals, etc. Other animals are grouped into large single terminators, such as 'insect.' Now that you have all your terminators broken down into two categories, the next step is to take one of the two categories and break it into two smaller categories. Continue in this fashion until ALL your catagories have been dismantled down to the terminator level. You should have something that looks like the decision tree in the previous section. Now let me diverge for a moment to discuss decision points, depth, and KB cleanliness. At every "fork" in the knowledge base you have what is called a decision point. Here is where the work of a KB is carried out. Depth is how far down in the KB you currently are. For example, in the previous decision tree chart: 2.wheels and 4.wheels are on the same level, and motor, bike, car, and truck are also on the same level, but a different level than 2.wheels and 4.wheels. Motor, bike, car, and truck are said to be a level "deeper" than 2.wheels and 4.wheels. As you break up your knowledge base you often separate terminators based on qualities you as KE have determined. For example, I used backbone as a determining factor in ANIMAL, but there really are several very high order qualifications for animals. The phylum Chordata is the only one having backbones, and it made up about half of my Page 16 terminators. Therefore, I chose backbone as the highest level qualifier. Now that you have your decision tree made there are two ways to write the KB: first, you can write each terminator with all of its qualifiers in each rule, or you can write rules for each decision point. If you remember your mathematics for expontial versus geometric expansion, you will see that it is better, and often easier to debug, if you choose the rule per decision point method. If you choose the former method not only would you be typing forever, but the KB may be too big to be operated on by an ESS. Ok. So you decide to start coding ANIMAL, and although it does not matter where in the tree you start or go to, I always start at the top and kind of work left to right. We have decided the initial question is going to be: "Does your animal have a backbone?", and you are going to set something based on the answer to that question. However, you can not determine the type of animal from the existence of a backbone, so you must create "level designators." These designators determine which path you take at any given level or decision point. Many times they are artificial. For example, I used the level designators in ANIMAL of SUPERPHYLUM, PHYLUM, CLASS, ORDER, FAMILY, GENUS, SPECIES, SUBSPECIES, and SUBSUBSPECIES. While these are, indeed, the qualifiers used in animal classification (except subspecies and subsubspecies), animal clasification does not follow the desired YES/NO, or binary, approach. Therefore, my level designators are artificial. Level designators are used to determine which path to take in the tree. It is a good idea to use one level designator per level in the tree, making sure that assignments to that designator are unique throughout the tree. A note about style and KB cleanliness here. Some practiced KEs will tell you that you can use the same level designator everywhere in the tree. This is true. However, if you use the same level designator everywhere in the tree debugging your KB may become impossible, because you have no idea where you currently are in a consultation. The trace function on many packages becomes nearly useless because you are always looking for the same thing. Point of interest: some texts may call the level designator the decision designator. Also, some KEs pick a unique designator for every decision point. You may do this if you like, and it may be useful on especially difficult KBs, but is not often required. One level designator per tree level is usually fine. Then begin coding your KB. The first rules will be the one concerning backbone. Page 17 if has.backbone is yes then superphylum is backbone if has.backbone is no then superphylum is jellyback Since you need this information from the user, you include the QUESTION rule: question has.backbone is "Does the animal have a backbone?" For the next rule in the KB you decide to go down the right hand side of the tree where the warm blooded qualifier splits up your terminators. Therefore you have to ask about the warm-bloodedness of your animal. Caution, here however, because the warm blooded attribute has nothing to do with the left side of the tree. Therefore, you have to make sure you are only dealing with the right side of the tree. To do this you incude an AND qualifier in the rules: if superphylum is backbone and warm.blooded is yes then phylum is warm if superphylum is backbone and warm.blooded is no then phylum is cold Several things to note here. First, we are going down a level in the tree, so phylum becomes our next level designator instead of superphylum. The superphylum part of the rule goes first, otherwise you would be asking your user questions that may not pertain to his animal, in this case about the animal's warm-bloodedness. In the above two rules you are again splitting the decision path in the decision tree. You will generally have one rule per link in the tree. You continue in this fashion until you have reached the terminators, upon where a rule will look like this: if species is notail and nearly.hairless is yes then type.animal is man ESIE works by tying in terminator rules with rules they reference, and rules those rules reference, etc., all the way to the top of the tree. In ANIMAL, the species part refers to a genus part, which refers to a order part, etc., all the way up to the backbone rules. Continue writing rules in this fashion until you have written an appropriate rule for every link, and an appropriate Page 18 question for every decision point. If you print out and read ANIMAL you will see what I'm talking about. You can reconstruct the decision tree I used by looking at the ANIMAL KB. The next thing you need to do is to tell ESIE which one of the qualifiers in the KB we are really looking for. This is the goal, or the reason for the consultation: goal is type.animal ESIE will stop the consultation when he finds out what type.animal is. You can learn more about how ESIE works by reading the manual that comes with this diskette and by paying for the source code that was used to build ESIE. By being fully structured, ANIMAL has a terminator for every path through the decision tree. No matter what the user responds, ESIE will come up with an animal for him. Page 19 Some Example Knowledge Bases Doctor DOCTOR is a non fully structured decision tree knowledge base. Non fully structured means different things to different AI researchers: for one it means that there are decision points in the tree that are not connected to the rest of the tree, for another it means that the ESS may not come up with a conclusion for every possible set of end user inputs. A few say it means both. In any case, I believe DOCTOR is both. I know it is the former. I gained the information in DOCTOR from a single book that has a few chapters on childhood diseases. As in building ANY knowledge base the first thing to do is obtain the knowledge. I began DOCTOR as I began ANIMAL: listing all the possible diseases that a child could have (finding all the terminators in the tree), and I gathered information about each one that would make it unique from the others. However, here is were the similarity ceases. I realized that my knowledge would be far from complete. That is, it would be nearly impossible for me to group the different diseases into categories based on the knowledge source I had. So, I simply started entering diseases into the KB, MAKING SURE THAT EVERY DISEASE ENTERED WAS UNIQUE FROM THE DISEASES ENTERED PREVIOUSLY. That is the key to making a non fully structured KB work. Although, with the KB given it, ESIE may ask some questions that have absolutely no pertinence as to the child's disease (i.e. he may or may not have the symptom and answering it will not help the determination), and the user may be asked to answer more questions than with a fully structured KB, but the KB will still be GREAT. When building a non fully structured KB you must look out for positioning in the rule base. It is the only time you must do so. Let me explain. When you have a KB that is not fully structured, rule positioning can be important. You need only worry about rule positioning if the <variables> in the conclusions are identical, and the comparators are similar. This becomes obvious in the following two rule example: if has.fever is yes then type.disease is roseola if has.fever is yes and has.inflammed.ears is yes then type.disease is serious.ear.infection Page 20 As ESIE is searching for 'type.disease' he comes across the first rule and invokes a QUESTION for has.fever. The end user specifies yes so ESIE concludes that type.disease is roseola and terminates this consultation. However, the child really had a serious ear infection, but ESIE never got that far. A better way to arange the rules would be: if has.fever is yes and has.inflammed.ears is yes then type.disease is serious.ear.infection if has.fever is yes then type.disease is roseola Now, when ESIE encounters the first rule he invokes a question to find has.fever. Since the answer is yes he invokes the QUESTION to determine if the child has inflammed ears. Since the answer is yes, ESIE reaches the correct conclusion that the type.disease is a serious ear infection. In general, you only need to worry about rule placement in the IF catagory, when the <variables> in the conclusion are identical, and the comparators are similar. Of course, if your information about 'roseola' was more complete you could simply add another rule to make it unique from serious ear infection. If your information is not complete, then you can add a rule like the one above to be your "catch all." If none of the other has.fever rules fire, then the disease must be roseola. Take a minute to look at the DOCTOR KB and compare it to the KB for ANIMAL. Any tree you try to put together for DOCTOR will look much different than the fully structured one for ANIMAL. Do not be fooled into thinking that the only type of KB you plan on doing is the fully structured kind. Nearly every usable KB is of the non fully structured variety, and, believe me, they are more than successful. Building structured KBs can often be nearly impossible. A system such as ANIMAL is often used as a learning tool in expert system education because biologists have spent lifetimes building schema to classify the animals, and it is possible to build fully structured knowledge bases with this very scientific, well documented, information. Page 21 Some Example Knowledge Bases Glass The GLASS KB is included simply for your edification and my delight. I did not build it. It is included to show another style of writing a KB. If you are new to ESs, then your style might be quite similar to the one in GLASS. I include it for my delight because it was built by a person with no AI experience or AI education at all. It shows how easy ESIE is to use. Software like ESIE may well help the spread of AI. Page 22 Building Your Own Knowledge Base The first thing you must do when you decide to build an AI tool is to decide what your area is. This may be a tough decision. It should be something were there is an abundance of information, and where that information can be translated into production rules. The area you are thinking about building an ES for is often called the "target" in AI parlance. In general, a KB is a set of problem and solution entities applied to the problem set. Since it may be difficult, or impossible, to code the decision-making process from the expert's frame of reference to the machine's, it is a good idea to spend a fair amount of time researching where you want to apply AI. ESs are generally required where human action or knowledge is not easily available to solve the problem or to make a decision. This may be occurring due to a shortage of qualified personel or due to the cost of hiring and training such personel. Another important criterion is that the "rules" the experts use to make a decision can easily be recalled by them. For example, you may be able to code the "rules" that go into the maintenance of a '57 Chevy, as they would obvious and explainable by a mechanic. However, the decisions a finance officer of a large corporation makes when investing in stock may be impossible to code into rules because he uses intuition to guide his decisions. Once the application has been decided on, then you must begin gathering knowledge in the form of production rules. These rules resemble an "IF-THEN" relationship. IF one thing is true THEN do another. For example, IF the car won't start THEN check the battery. Defining these IF-THEN rules, by interviewing and consulting experts in the target field, is how you build a KB. It is important to check the qualifications of the expert as well as the dedication of the expert to develop the system. A common language to be used between you and the expert(s) should be developed right away. Communication is essential! This common speaking ground should be mnemonic and very easy to use. A review of the KB and KB structure with as many of the experts who helped you develop the knowledge base is almost always a good idea. They will tell you where they said one thing yet meant another, or possibly were you made a mistake in creating a production rule. Page 23 However, you may find it worthwhile to train the experts in the building of the knowledge base themselves. An even greater possibility for success comes if you are an expert in a field and choose that field to be built into a KB. Often, experts prefer developing systems in this manner instead of being interviewed by a programmer who might not have excellent communications skills. Some might even get carried away and develop a system par none. ESIE is very easy to use, and the expert might even have some fun coding his knowledge into a KB. Most people like to show off their expertise when given a chance! The gathering of information is often the toughest and the most discouraging step in building a KB. I urge you not to give up if it seems impossible or is very frustrating. It will probably fall very easily into place when you start building the KB. Do not worry if you do not have complete knowledge, or that your knowledge is only rudimentary when you start building the ES: you can, and should, go back to the expert to ask new questions as the KB takes form. One of the best possible situations is when you are also the expert that is building the KB. It is usually pretty easy to ask yourself questions. Most people have many things that they are very good at. Several of these might be built into KBs. I assume there is something you are an expert in and can put your information into some production rules. This is often one of the most productive environments for building KBs. Try it: you may even find that someone wants to buy it from you. If you are your own expert in building a KB, try to do two things: 1) be objective. If you have an area that you are a little fuzzy about, or where there is significant difference of opinion among your technical peers, then get a second or third opinion. 2) be understanding. Allow a person not versed in your field to use the system as it begins taking shape. He/she will often tell you where something doesn't make sense. While it makes sense to you and is perfectly obvious, remember that you are building this system to help the kind of person sitting in that chair. After you have gathered a good chunk of information, or at least enough to get started, you should start entering the knowledge as rules in the KB. In ESIE there are five kinds of rules. Now would be a good time to read The ESIE Rule Structure in the manual. What you read in that section will be the types of rules entered into the KB. When you get started with building your KB you will find that building these types of rules often comes naturally and intuitively. No real work should be expended in translating knowledge into rules. If it is a chore for you, then relax: you are trying Page 24 too hard, probably to keep the KB structured and coherent. Do not attempt this at first. You can always go back and make the KB "pretty" after the knowledge is in there. Simply think about the information you have and how that would look translated LITERALLY into an IF-THEN construct. Then type that in. Entering rules in the KB is easy. You use your own word processor (see the section on ESIE Requirements in the manual to make sure your editor is compatible) and type in the rules as you would type in a letter to an old friend. The rules in ESIE can be entered into the KB in free format. That is, the KB can look pretty strange when you are through with it. For example, the following two KBs are identical: goal is type.animal if has.backbone is yes and has.finger.wings is yes then type.animal is bat question has.backbone is "Does it have a backbone?" question has.finger.wings is "Does it have finger wings?" answer is "Your animal is a " animal.type and this one: goal is type.animal if has.backbone is yes and has.finger.wings is yes then type.animal is bat question has.backbone is "Does it have a backbone?" question has.finger.wings is "Does it have finger wings?" answer is "Your animal is a " animal.type I recommend something like the former structure. I might suggest, dear reader, that you make a couple of "play" KBs just to get used to ESIE, before you really dig in with the real world ones. Follow the guidelines for ESIE outlined in The ESIE Rule Structure, and I'm sure you will have no problem. Although I would love to help everyone out there who is trying to debug a KB, I will offer telephone support only to the individuals who have paid the $145 price for ESIE. When you have enough rules in a KB to make a simple run, I recommend that you test what you have. To do this, simply start ESIE and enter your KB filename in place of ANIMAL. When you get to the top level I suggest you turn trace on until you have the KB fully debugged. When trace is on ESIE will keep you informed of what it is doing. It will tell you what it is currently looking for and what it has learned. Page 25 ESIE learns things when a QUESTION is answered and when a rule is "satisfied." Run through your KB, testing every path to your terminators using the GO command. Good luck! (I know, you are not superstitious, but it can't hurt, can it?) One of the best hints I can give you is to use mnemonic names for your <variables> and <values>. I can remember cringing when I was asked to help debug a KB with all the <variables> assigned a letter designator: A1 to A287. For the LEGALANSWERS type rule I suggest you try to restrict the end user responses to as few responses as possible. And, if you want to offer multiple responses, make a valid response for one question be an impossible answer for another, unrelated question. For example, if the question is about what time of day it is, and you want him to answer morning or afternoon, do not have numbers as legal reponses or specifically ask him if it is morning or afternoon. An unexpected response may make the consultation useless. The GOAL type rule is fairly self explanatory. I think we've talked enough about the IF-THEN rule type. On the QUESTION rule type try always to "beg the question" or "bait the response" as it is sometimes called. Remember what you will accept as valid answers and try to get the user to give you one of those answers through the question you are asking. Always try to be friendly, or at least not hostile, in your questioning. A good trick is to shorten the length of your questioning as you get deeper into the KB. As this happens, the user will already have answered several questions and may not care to continue with all the verbage. You might substitute: "Does it have wings?" for "Does the animal you are thinking about have wings?" if you have already asked several questions. In the ANSWER type rule remember to leave a space at the end of your <text> if you want one. Try to phrase the <text> so that it accounts for every possible <value> of the <variable>. Be descriptive and friendly, but remember that the user has just been through a consultation, so superfluous verbage is not needed. Most of all, have fun with what you are doing! Page 26 Paying For and Obtaining the Next Version of ESIE Now comes the part we all hate to discuss. What is ESIE going to cost? Well, that is totally up to you. I happen to be one of those people that believe that most people are honest and will pay for something they find useful. I also believe that most software costs too much, and that all AI software costs way too much. I dislike copy protection schemes and there are none in ESIE. And I believe that you will want to see ESIE grow and be supported. If you feel that ESIE is useful to you, send what your conscience dictates. However, if you send at least $75 you will receive the most recent version of ESIE, free. If you send at least $145 you will receive: the most recent version of ESIE, fully commented source code for ESIE (ESIE was written in Pascal), my sincere thanks for your support, a copy of PC-Write (c) - a shareware full-feature text editor fully compatible with ESIE, and access to a help line, all free. Regardless of how you feel towards ESIE, I ask that you do two things: 1) Print and fill out the file FORM so that I may keep improving ESIE, and 2) share copies of the distribution diskette with at least two people, preferably one of them outside your organization. I think of ESIE as living software: software that continues to develop and get better, more powerful. I believe ESIE is a useful tool as it is, but can be improved. However, support for living software must come from somebody. Even we software authors and AI researchers can't live on discovery and love alone. In shareware this support comes from you - the user. Mail and money for ESIE can be sent to: Lightwave Consultants; P.O. Box 290539; Tampa, FL 33617. Page 27 Bibliography 1. Dr. Herbert Simon, "AI - The Realty and the Promise"; in his lecture at "Artificial Intelligence -- Opportunities and Limitations in the 80's", Miami, Florida; November 7, 1984. AI Intelligence Report; Sendero; Phoenix, Arizona; April, 1985. AI Magazine; American Association for Artificial Intelligence; Menlo Park, CA; Fall 1985. AI Magazine; American Association for Artificial Intelligence; Menlo Park, CA; Winter 1985. Applied Artificial Intelligence Reporter; University of Miami; Miami, Florida; October 1984. Executive Briefing Artificial Intelligence; Longman Crown; Reston, Virginia; 1984. The First Conference on Artificial Intelligence Applications; Sponsered by the IEEE Computer Society; Denver; Decemeber 5-7, 1984. Proceedings: AI - Opportunities and Limitations in the 80's; ICS Research Institute, University of Miami; Miami, Florida, November 7, 1984. Proceedings: IEEE Workshop on Principles of Knowledge-based Systems; Sponsored by the IEEE Computer Society; Denver; December 3-4, 1984. Page 28 Biography I think it important that I tell you a little about who I am. My name is Edward Reasor, and I own and operate Lightwave Consultants. My Artificial Intelligence training began in college, but was not used for some time afterward, as I was employed in a rather traditional DP environment. After having worked for this Fortune 500 company for a few years, a co-worker and I convinced management that the time was right to use AI. After building the AI research department, and working in that department for a few years, I struck out on my own. I have several expert systems to my credit, the names of which can not be disclosed here. I am a member of the American Association for Artificial Intelligence and the Institute of Electrical and Electronics Engineers.